home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
rdisc
/
rdisc-minutes-89dec.txt
< prev
next >
Wrap
Internet Message Format
|
1993-02-17
|
12KB
Return-Path:
Received: from pescadero.stanford.edu by NRI.NRI.Reston.VA.US id aa09367;
6 Jan 90 18:43 EST
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA08497; Sat, 6 Jan 90 15:45:16 PDT
Date: 6 Jan 1990 15:30-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Router Discovery WG meeting report
To: gvaudre@nri.reston.va.us, pgross@nri.reston.va.us
Message-Id: <90/01/06 1530.279@pescadero.stanford.edu>
Greg and Phill,
Here are the minutes of the first meeting of the Router Discovery WG,
for you to file away. Note that the minutes refer to "gateway" discovery,
rather than "router" discovery, which was our terminology at that time.
Steve
--------------------------------------------------------------------
Gateway Discovery Working Group
Chairperson: Steve Deering/Stanford
REPORT ON MEETING OF DECEMBER 12, 1989
at DEC Western Research Lab, Palo Alto, CA.
Reported by Steve Deering
ATTENDEES
1. Art Berggreen art@salt.acc.com
2. Noel Chiappa * jnc@ptt.lcs.mit.edu
3. Farokh Deboo sun!iruucp!ntrlink!fjd
4. Steve Deering deering@pescadero.stanford.edu
5. Richard Fox sytek!rfox@sun.com
6. Keith McCloghrie sytek!kzm@hplabs.hp.com
7. Jeff Mogul mogul@decwrl.dec.com
8. Stephanie Price cmcvax!price@hub.ucsb.edu
9. Greg Satz satz@cisco.com
* Noel Chiappa attended by speaker phone.
MINUTES
This was the first meeting of the Gateway Discovery Working Group,
although it has been very active by email since it was formed on
October 27, 1989. The meeting was held back-to-back with the first
MTU Discovery Working Group meeting. Our thanks to Jeff Mogul and
DECWRL for hosting the meeting.
As the first item of business, Deering suggested that the group might
wish to elect a new chairperson, because of potential conflict-of-
interest on his part. (As the designer of one of the candidate
gateway discovery protocols, he might not be sufficiently impartial.)
The attendees chose not to take him up on his suggestion.
We then reviewed the various candidate gateway discovery protocols that
had been identified and discussed on the mailing list:
stub RIP - using default-route-only RIP broadcasts to inform
hosts of gateway presence; usable by any gateway,
not just those using RIP as their IGP.
cisco GDP - a UDP-based protocol very similar in functionality
to the IS-discovery part of the ISO ES-IS protocol.
ICMP-D - Deering's proposed ICMP extensions, based on low-
frequency periodic multicasts by gateways (i.e.,
not frequent enough for timely detection of gateway
failure).
ES-IS subset - the gateway-discovery/gateway-failure-detection
subset of ISO 9542, with the minimum of changes
required to carry IP addresses in IS Hellos.
Proxy ARP - eliminating the need for "gateway discovery" by
making the gateways invisible.
PP1 - Prindeville's proposal #1, in which an IP unicast
datagram is sent as a LAN multicast packet when
no gateway address is known, triggering a Redirect.
PP2 - Prindeville's proposal #2, in which hosts send ICMP
multicast queries to locate gateways. The proposal
was unclear on whether or not queries are for a
specific destination/TOS, or for default gateway only.
[It has since been clarified: the queries are for
specific destination&TOS.]
X.Y.Z.1 - using a well-known address (such as address number 1
on every subnet) to identify the "current default
router". The routers run an election algorithm to
decide which one answers to that address at any time.
BOOTP - three popular protocols used to supply hosts with
Sun BootParam one or more gateway addresses (along with other info)
MIT NIP at boot time. Might be extended to supply gateway
addresses at other times.
The list was then trimmed to three candidates -- RIP, GDP, ICMP-D --
for further discussion. The others were eliminated for the following
reasons:
ES-IS - use of ISO packet formats unnecessarily complicates
implementation on simple IP-only hosts; no "preference
level" field; political hot-potato.
Proxy ARP - if hosts don't know they are talking to a gateway, they
won't obey Redirects; difficult for gateways to decide
which is "best" choice; "slowest gateway wins" phenomenon.
PP1 - difficult for gateways to decide which is "best" choice;
Redirect implosion; duplicate delivery.
PP2 - incomplete specification; scales poorly with large numbers
of hosts.
X.Y.Z.1 - won't work with existing hosts that don't time out ARP
entries; too late to reserve a special address on all
subnets.
BOOTP, BootParam, NIP - not designed for dynamic, on-going discovery
of gateway addresses; hosts might get confused on receiving
an unsolicited, partial BOOTP broadcast; beyond charter of
this group.
We then proceeded to identify the following pros and cons of stub RIP:
Pro: - already supported by many hosts and gateways.
Con: - uses broadcast rather than multicast.
- is named "RIP" -- it has become politically incorrect
to advocate the continued use of RIP. (Possibly solved
by giving the stub RIP subset a new name?)
- no "holding time" field, which is important if doing
ES-IS-style gateway failure detection. It means that
hosts have to have wired-in knowledge of the gateway
broadcast rate, which would have to be 30 seconds for
the scheme to work with existing RIP implementations.
Unfortunately, 30 seconds is too long for reasonable
dead gateway detection, and much shorter than needed
for discovery only.
- [not mentioned at the meeting, but in an earlier mail
message: danger of stub-RIP broadcasts from non-RIP gateways
confusing full-RIP gateways on the same wire.]
We also discussed using full RIP packets (i.e., containing per-
destination routes, rather than just default routes) for the sake
of multi-homed hosts, which have to do more than just discover
a default gateway. By comparing routing metrics reported on
each connected subnet, a multi-homed host can decide which subnet
to use as the first hop towards a given destination. However,
RIP is less than ideal for this application, because:
- RIP packets do not carry Autonomous System numbers,
which would allow hosts to know whether or not RIP
metrics from different subnets can sensibly be compared.
- RIP routes are per-destination only, rather than
per-destination&TOS.
- The RIP packet encoding for IP routes is very inefficient,
which means that large routing tables must be split across
more packets than necessary.
Unlike RIP, the remaining two candidates -- GDP and ICMP-D -- are
amenable to change (no need for backward compatibility). Therefore,
rather than going through the pros and cons of each protocol, we
identified the differences between the two and agreed on a resolution
of those differences, thus coming up with the "best" of the two.
Those differences are:
- GDP is a UDP application; ICMP-D is an ICMP extension.
Resolution: use ICMP. This is the logical place for this
functionality in the IP suite. It was recognized that it is
generally easier to add UDP applications to an existing
implementation than to extend ICMP, but that the need for the
protocol to manipulate the IP default gateway list might be
more easily met by an ICMP-level implementation in some cases.
It was noted that, for 4.3bsd Unix and derivatives (e.g., current
versions of SunOS and Ultrix), the required ICMP extensions can be
implemented either inside the kernel or in a user-level process.
- GDP uses broadcast; ICMP-D uses multicast.
Resolution: specify the use of multicast, but recognize that some
vendors and network administrators will use broadcast anyway, at
least until hosts and gateways are upgraded to support multicast.
Therefore, discourage the use of broadcast but do not forbid it
("SHOULD multicast").
- GDP includes a "holding time" field; ICMP-D does not.
Resolution: include a holding time field. This field allows a
gateway to control how long a host continues to believe that
the gateway is alive, in the absence of new information; it is
important if the protocol is to be used for gateway failure
detection as well as gateway discovery, and is useful in any
case. (There is some controversy over how gateway failure
detection ought to be done and, in order to progress the
gateway discovery protocol, we are putting off resolution
of that issue for now. It is expected that this working group
will evolve into the "black-hole detection" working group
after it's initial charter has been satisfied. Including the
holding time field in the packet format will leave the options
open for that future work.)
- GDP allows more than one gateway address to be reported in a
single packet; ICMP-D only allows one (the IP source address
of the packet.
Resolution: allow more than one gateway address. This is NOT
intended to allow one gateway to report other gateways' addresses
(although it does permit such usage); it is for gateways connected
to LANs that carry more than one IP subnet, where a gateway may
have a different address for each subnet. Hosts receiving the
gateway reports must pick out only those addresses that belong
to the same subnet as the host, and ignore the rest.
- GDP does not carry subnet masks in its gateway reports; ICMP-D does.
Resolution: do NOT include subnet masks. This means that,
before engaging in the gateway discovery protocol, a host must
know its own mask (as well as its own address). There are already
several existing mechanisms for acquiring that information, e.g.,
static configuration, BOOTP, and ICMP Mask Reply; it is expected
that the Host Configuration Working Group will standardize on a
mechanism for obtaining various subnet parameters, of which the
mask is only one.
- GDP allows for 2^16 preference levels (priorities); ICMP-D allows
for only 8 preference levels.
Resolution: no big deal, but 8 levels should be sufficient.
However, there is some doubt as to the value of including
preference levels at all. The working group does not want to
specify at this time how hosts shall deal with preference levels,
but agrees to include the field for private use or possible
consideration at a later time.
- GDP does not specify randomization of periodic gateway reports
(to avoid synchronized transmissions) or any mechanism to
reduce the traffic during simultaneous boot-up by many hosts;
ICMP-D specifies both.
Resolution: specify randomized reporting intervals; the ICMP-D
mechanism for replying to multiple multicast queries with a single
multicast reply is to be suggested but not required.
Deering volunteered to revise his draft RFC to reflect these decisions,
to be ready by the February IETF meeting.
Greg Satz generously agreed to let us use his (cisco's) BSD Unix
implementation of GDP as the basis of a freely-distributable
implementation of the revised protocol. We hope to have that ready
by the February meeting as well.
The next meeting of the Gateway Discovery Working Group will be at the
February IETF meeting in Tallahassee, Florida. We intend to split
a single afternoon session between us and the MTU Discovery Working
Group, which has many of the same members.